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From: Evangelos E. Melagrakis <eem@elot.gr> 

To: b paterson <100611.2060@CompuServe.COM> 
Subject: EURO and 2-column char sets 

Date: Tpit, 4 NoepBpiov 1997 11:04 mu 


Dear Mr. Paterson, 


During the Dublin meeting of CEN/TC304, we had an extensive discussion on the EURO 
issue as well as on the issues closely related to it, like for example the proposed Latin 0 part 
of ISO 8859. It has been made apparent from these discussions, at least to me, that there are 
too many different (and difficult) problems to be tackled and that there is no unanimity 
towards a single solution. 


Summarizing these discussions, I could identify a number of issues: 

- The need for the introduction of the EURO sign in code tables that we could use 
immediately. 

- The need not to change anything in well established code tables like for example those 
derived from ISO/IEC 8859. 

- The strategic need to support the implementation of ISO/IEC 10646. 

- Many countries (e.g. France, Romania, Finland) can satisfy their needs with an existing 
part of ISO/TEC 8859 but they need a small number of additional characters. 

- The major vendors are reluctant to support additional code tables or parts of 8859, 
especially when these tables are similar to existing ones. 

- In addition, the code tables supported by these vendors do not conform exactly to the 
provisions of ISO 2022, ISO 4873, ISO 8859, ISO 2375. 


These are some of the issues discussed. Of course, you do not need an exhaustive explanation 
of these issues from me, as you are already aware of the situation. 


I discussed a proposal of mine, unofficially, with several of the delegates present in the 
Dublin meeting. The proposal is not a new one, in the sense that its principles have been 
discussed in the past. In short, the proposal is to register 2-column graphic character sets and 
to immediately proceed with an amendment of ISO/TEC 2022 that will permit us to do so. 


Remember ENV 41505, the Symbols set? 


I know that changing ISO/IEC 2022 is not an easy task. Since 1989, I am using extensively 
the techniques of ISO/IEC 2022 for conversion purposes. Therefore I am aware that many 
paragraphs of the Standard should be carefully amended, in order to allow 2-column sets with 
non-control characters to be designated and invoked in the columns 08 and 09, that is the 
former C1 area. 


I discussed this proposal with several delegates, mostly from vendors (e.g. IBM, Microsoft), 
with national delegates and with Mike Ksar. What I heard from all is that: 

Vendors do not like to continue to produce more and more 8-bit code pages each time 
someone discovers a small new need, say to add or subtract one or two characters in a whole 
code page (it is too costly and too complicated, they said). 

The major vendors that support operating systems have already violated the C1 area and have 
already placed graphic characters there, so it is only natural for them to support the idea of 
registering 2-column non-control character sets. 
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Mike Ksar proposed to contact you to discuss this idea of registering 2-column non-control 
character sets in the C1 area with you, and that is what I am now doing. 


I see clear benefits from this proposal. 


The major software players will have the chance to conform exactly to the International 
Standards, instead of violating them continuously, as it has always been the case so far. One 
may say of course that the Standards will now conform to the actual situation in the market, 
but this is what standardization is about. 


I believe that we can satisfy a lot of needs by registering 2-columns non-control character 
sets. I insist on using the term "non-control" instead of graphic because I see these 2-column 
sets as serving rather special purposes instead of being only supplements to normal graphic 
character sets. For example we can use them to code combining characters, characters that are 
needed in many scripts, like EURO, characters that are of special use like for example the bi- 
directional characters of the Hebrew part etc. etc. 


I will be grateful if you send me urgently your thoughts on this proposal. If, besides the 
obvious difficulties of amending ISO 2022, you are positive to this idea, then I have another 
suggestion. I intend to send out immediately the proposal for the revision of ISO 2022, (e.g. 
the proposal can be initiated from my National Standards Body) with you as the proposed 
project leader. Would you accept that? 


Best regards, 


Evangelos Melagrakis 
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From: b paterson 10061 1.2060@compuserve.com 
To: Evangelos E. Melagrakis eem@elot.gr 

Ce: Mike Ksar mike_ksar@hp.com 

Subject: EURO and 2-column char sets 

Date: Kuptaxnh, 9 NoeuBpiov 1997 7:22 uyu 


Dear Mr Melagrakis —_9'" November 1997 


Thank you for your interesting message about the problems of 8859 Parts, and all the new 
characters still needed for them. 


You said: 
I believe that we can satisfy a lot of needs by registering 2-columns non-control character 
sets. 


The major software players will have the chance to conform exactly to the International 
Standards, instead of violating them continuously, as it has always been the case so far. One 
may say of course that the Standards will now conform to the actual situation in the market, 
but this is what standardization is about. 


Well, I do agree with all that. 

What I would like to see is a proposal that describes the requirements, that we could discuss 
more widely by email. I think it is important to state requirements before we jump into 
describing the solution. 


The primary requirements seem to be: 

A. In an 8-bit single-byte code, to utilize the code positions of columns 08 and 09 for a set of 
32 characters that includes graphic characters, as well as control characters that are at present 
permitted by ISO/IEC 4873. 

B. To specify one or more sets of 32 characters, comprising control characters AND graphic 
characters, as Supplementary Sets for use in the C1 area of an 8-bit code table. 

C. The functions of the control characters in such a set shall be directly related to the 
processing or presentation of the graphic characters in the CC-data-elements in which they 
appear. 

D. Interworking with ITU-T Videotex services, or other applications which use existing C1 
controls for any purposes, is not a requirement. 


A suitable name for such 32-character sets is- 
A SET OF 32 GENERAL CHARACTERS 


They could be specified in a separate standard, for use with existing Parts of ISO/IEC 8859, 
or could be a Revision of ISO/IEC 2022. 


Since ISO/TEC 2022 covers such a wide range of options, we would need to state clearly 

which options we would expect to use, in conjunction with the new "Supplementary General" 

32-character sets e.g.: 

- Level 1 (no shifts), or Levels 2 and 3 (single and locking shifts)? 

- Multi-byte graphic character sets (I hope not! )? 

-  §8-bit coding only, or 7-bit coding also? 

- Is the existing Designation function (escape sequence) for C1 sets sufficient, or should it 
be amended? 
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- Isanew Announcer function (escape sequence) needed? 
- Any other questions? 


It would also be good to have at least ONE example of a useful 32-character set (including the 
EURO symbol) for registration as a C1 set, for discussion. 


The above text, between the rows of ------------ gives you a first draft of the Requirements. 
Personally I do not wish to commit myself to a lot more work on ISO standards. But if a set of 
requirements can be agreed in principle by the major software implementers, and then 


presented to SC2/WG3, amendments. 


Regards, -Bruce P. 


